-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add script to build migrations with datastore plugin #126
Conversation
gammazero
commented
Mar 20, 2021
- Update documentation
@aschmahmann status? |
@gammazero do you mind rebasing this on master and then we can do a walkthrough on how this works and make sure the script is mergeable? |
0344c82
to
b396d4b
Compare
I needed to update the go-ipfs dependency for |
@gammazero hmmm... I see we accidentally did a force push ipfs/kubo#7857 (comment). I restored the branch but we should probably update anyway. If the script works now that I've restored the old branch then let's drop the update from this PR and just do it in another one ideally once the next go-ipfs release is out. Otherwise, we can make a PR that just updates the deps now and have this PR build off of that one. I want this PR to be two files instead of 700 😄 |
b396d4b
to
7452cb4
Compare
@aschmahmann After restoring the old branch, the script works. Now the PR has only one change. |
The distribution at /ipfs/QmaaN2kipZfUpRSzwvUeG4Xi3yp1JJB294Vj8pnZ24hesF is no longer available and this is causing a sharness test to fail. Updated the test to use the current distribution.
build-plugin.sh
Outdated
@@ -0,0 +1,118 @@ | |||
#!/bin/bash | |||
# | |||
# Building migrations with datastore plugin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much of this is datastore specific, or just arbitrary Go plugins (e.g. could IPLD plugins work too)?
I see there are some implied datastore plugin names, but the plugin names could be separately specified. Is there anything else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assumed this was only for datastore plugins, but I guess it could be built with any. This is just for building a filestore repo migration, so does it even make sense to support any plugin? I do not know.
Do I need to add another argument, or prompt, for the name of the plugin?
build-plugin.sh
Outdated
|
||
function usage() { | ||
echo "usage: $0 plugin_repo x-to-y ...">&2 | ||
echo "example: $0 github.com/ipfs/go-ds-s3 10-to-11" >&2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two feature requests I'd add here, that can happen after we merge this initial one but would be nice to have are:
- Being able to choose the version of the repo not just the repo itself (e.g. I might need to build an old migration against an old version)
- Being able to add multiple plugins to a given binary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- A user can now specify the version of the migration by following it with
@<version_or_hash>
- The script builds a single migration, with one or more plugins.
Example:
./build-plugin.sh 10-to-11 github.com/ipfs/go-ds-s3 github.com/ipfs/go-ds-swift@v0.1.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, looking forward to giving this a spin.
Script now builds one migration, but with any number of specified plugins. Example `./build-plugin.sh 10-to-11 github.com/ipfs/go-ds-s3 github.com/ipfs/go-ds-swift@v0.1.0`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the job for the repos tested, but makes some assumptions about the plugins system we should spell out.
Also, let's add a note in the README that this script exists and might be very useful to people who are running into problems migrating their go-ipfs nodes that use plugins.
build-plugin.sh
Outdated
local plugin_name="$(echo $plugin_repo | rev | cut -d '-' -f 1 | rev)" | ||
local ds_name="${plugin_name}ds" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure that the name of the plugin as added to the preload_list is only used for populating the import directives in the code generation script https://github.com/ipfs/go-ipfs/blob/master/plugin/loader/preload.sh.
It'd be nice if the user could set this in case they somehow end up with a conflict, but I don't think it should matter/come up for almost anyone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
When a plugin name conflict is detected, suggest a new name by appending a "1" to the current name. If running interactive, then ask the user to use the new name or provide one. If running non-interactive, then keep appending "1" until no conflict.
build-plugin.sh
Outdated
pushd "$BUILD_GOIPFS" | ||
go get "${plugin_repo}@${plugin_version}" | ||
popd | ||
echo "$ds_name ${plugin_repo}/plugin 0" >> "${BUILD_GOIPFS}/plugin/loader/preload_list" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${plugin_repo}/plugin 0
This part is incorrect/needs to be configured by the user. The actual subpackage that the plugin is in is totally configurable by the user and so should be something passed in by the user. This doesn't seem like it's too bad since we can just rip it off of the URL that's passed in.
The 0
part is hopefully fine for almost everyone, but technically this can either be any number or '*' and the user should be able to configure it. This is maybe more annoying to pass in, if we needed to default to something maybe choose *
since it's what we use in our preload examples https://github.com/ipfs/go-ipfs/blob/0ae9b2b9034a57e02df419fe72f705f5a5b3b9c7/plugin/loader/preload_list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this needs to be specified for each plugin that is build, I think it makes for a much less messy command line if the user is asked interactively about which plugin to load. Now, for each plugin repo build, the user gets a prompt that looks like:
For github.com/ipfs/go-ds-s3, load 'plugin *' [y/n]?
If they answer n
, then they are asked to for a different value.
The prompting can be avoided by using the -y
flag as the first argument to the scipt.
When a plugin name conflict is detected, suggest a new name by appending a "1" to the current name. If running interactive, then ask the user to use the new name or provide one. If running non-interactive, then keep appending "1" until no conflict.
- README describes how to use the build-plugin.sh script to build a migration with plugins. - Display help with `build-plugin.sh -h`
@aschmahmann Added section to README to describe |